With the project loaded in Visual Studio, take a look
at the Solution Explorer for the project. You’ll see two pairs of
skeleton files: App.xaml and App.xaml.cs, and MainPage.xaml and MainPage.xaml.cs. The App.xaml and MainPage.xaml files are Extensible Application Markup Language (XAML) files, while App.xaml.cs
and MainPage.xaml.cs are C# code files. This peculiar naming scheme is
meant to imply that the two C# code files are “code-behind” files associated with the two XAML files. They provide code in support of the markup. This is a basic Silverlight concept.
I want to give you a little tour of these four files. If you look at the App.xaml.cs file, you’ll see a namespace definition that is the same as the project name and a class named App that derives from the Silverlight class Application. Here’s an excerpt showing the general structure:
Example 1. Silverlight Project: SilverlightHelloPhone File: App.xaml.cs (excerpt)
namespace SilverlightHelloPhone
{
public partial class App : Application
{
public App()
{
. . .
InitializeComponent();
. . .
}
. . .
}
}
|
All Silverlight programs contain an App class that derives from Application; this class performs application-wide initialization, startup, and shutdown chores. You’ll notice this class is defined as a partial class, meaning that the project should probably include another C# file that contains additional members of the App class. But where is it?
The project also contains an App.xaml file, which has an overall structure like this:
Example 2. Silverlight Project: SilverlightHelloPhone File: App.xaml (excerpt)
<Application
x:Class="SilverlightHelloPhone.App"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:phone="clr-namespace:Microsoft.Phone.Controls;assembly=Microsoft.Phone"
xmlns:shell="clr-namespace:Microsoft.Phone.Shell;assembly=Microsoft.Phone">
. . .
</Application>
|
You’ll recognize this file as
XML, but more precisely it is a XAML file, which is an important part of
Silverlight programming. In particular, developers often use the App.xaml file for storing resources that are used throughout the application. These resources might include color schemes, gradient brushes, styles, and so forth.
The root element is Application, which is the Silverlight class that the App class derives from. The root element contains four XML namespace declarations. Two are common in all Silverlight applications; two are unique to the phone.
The first XML namespace
declaration (“xmlns”) is the standard namespace for Silverlight, and it
helps the compiler locate and identify Silverlight classes such as Application itself. As with most XML namespace
declarations, this URI doesn’t actually point to anything; it’s just a
URI that Microsoft owns and which it has defined for this purpose.
The second XML
namespace declaration is associated with XAML itself, and it allows the
file to reference some elements and attributes that are part of XAML
rather than specifically Silverlight. By convention, this namespace is
associated with a prefix of “x” (meaning “XAML”).
Among the several attributes supported by XAML and referenced with this “x” prefix is Class, which is often pronounced “x class.” In this particular XAML file x:Class is assigned the name SilverlightHelloPhone.App. This means that a class named App in the .NET SilverlightHelloPhone namespace derives from the Silverlight Application class, the root element. It’s the same class definition you saw in the App.xaml.cs file but with very different syntax.
The App.xaml.cs and App.xaml files really define two halves of the same App class. During compilation, Visual Studio parses App.xaml and generates another code file named App.g.cs.
The “g” stands for “generated.” If you want to look at this file, you
can find it in the \obj\Debug subdirectory of the project. The App.g.cs
file contains another partial definition of the App class, and it contains a method named InitializeComponent that is called from the constructor in the App.xaml.cs file.
You’re free to edit the
App.xaml and App.xaml.cs files, but don’t mess around with App.g.cs.
That file is recreated when you build the project.
When a program is run, the App class creates an object of type PhoneApplicationFrame and sets that object to its own RootVisual property. This frame is 480 pixels wide and 800 pixels tall and occupies the entire display surface of the phone. The PhoneApplicationFrame object then behaves somewhat like a web browser by navigating to an object called MainPage.
MainPage is the second major class in every Silverlight
program and is defined in the second pair of files, MainPage.xaml and
MainPage.xaml.cs. In smaller Silverlight programs, it is in these two
files that you’ll be spending most of your time.
Aside from a long list of using directives, the MainPage.xaml.cs file is very simple:
Example 3. Silverlight Project: SilverlightHelloPhone File: MainPage.xaml.cs (excerpt)
using System;
using System.Collections.Generic;
using System.Linq;
using System.Net;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Documents;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Animation;
using System.Windows.Shapes;
using Microsoft.Phone.Controls;
namespace SilverlightHelloPhone
{
public partial class MainPage : PhoneApplicationPage
{
// Constructor
public MainPage()
{
InitializeComponent();
}
}
}
|
The using directives for namespaces that begin with the words System.Windows are for the Silverlight classes; sometimes you’ll need to supplement these with some other using directives as well. The Microsoft.Phone.Controls namespace contains extensions to Silverlight for the phone, including the PhoneApplicationPage class.
Again, we see another partial class definition. This one defines a class named MainPage that derives from the Silverlight class PhoneApplicationPage. This is the class that defines the visuals you’ll actually see on the screen when you run the SilverlightHelloPhone program.
The other half of this MainPage class is defined in the MainPage.xaml
file. Here’s the nearly complete file, reformatted a bit to fit the
printed page, and excluding a section that’s commented out at the end,
but still a rather frightening chunk of markup:
Example 4. Silverlight Project: SilverlightHelloPhone File: MainPage.xaml (almost complete)
<phone:PhoneApplicationPage
x:Class="SilverlightHelloPhone.MainPage"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:phone="clr-namespace:Microsoft.Phone.Controls;assembly=Microsoft.Phone"
xmlns:shell="clr-namespace:Microsoft.Phone.Shell;assembly=Microsoft.Phone"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
mc:Ignorable="d" d:DesignWidth="480" d:DesignHeight="768"
FontFamily="{StaticResource PhoneFontFamilyNormal}"
FontSize="{StaticResource PhoneFontSizeNormal}"
Foreground="{StaticResource PhoneForegroundBrush}"
SupportedOrientations="Portrait" Orientation="Portrait"
shell:SystemTray.IsVisible="True">
<!--LayoutRoot is the root grid where all page content is placed-->
<Grid x:Name="LayoutRoot" Background="Transparent">
<Grid.RowDefinitions>
<RowDefinition Height="Auto"/>
<RowDefinition Height="*"/>
</Grid.RowDefinitions>
<!--TitlePanel contains the name of the application and page title-->
<StackPanel x:Name="TitlePanel" Grid.Row="0" Margin="12,17,0,28">
<TextBlock x:Name="ApplicationTitle" Text="MY APPLICATION"
Style="{StaticResource PhoneTextNormalStyle}"/>
<TextBlock x:Name="PageTitle" Text="page name" Margin="9,-7,0,0"
Style="{StaticResource PhoneTextTitle1Style}"/>
</StackPanel>
<!--ContentPanel - place additional content here-->
<Grid x:Name="ContentPanel" Grid.Row="1" Margin="12,0,12,0">
</Grid>
</Grid>
</phone:PhoneApplicationPage>
|
The first four XML namespace declarations are the same as in App.xaml. As in the App.xaml file, an x:Class attribute also appears in the root element. Here it indicates that the MainPage class in the SilverlightHelloPhone namespace derives from the Silverlight PhoneApplicationPage class. This PhoneApplicationPage class requires its own XML namespace declaration because it is not a part of standard Silverlight.
The “d” (for “designer”) and “mc”
(for “markup compatibility”) namespace declarations are for the benefit
of XAML design programs, such as Expression Blend and the designer in
Visual Studio itself. The DesignerWidth and DesignerHeight attributes are ignored during compilation.
The compilation of the program generates a file name MainPage.g.cs that contains another partial class definition for MainPage (you can look at it in the \obj\Debug subdirectory) with the InitializeComponent method called from the constructor in MainPage.xaml.cs.
In theory, the App.g.cs and MainPage.g.cs
files generated during the build process are solely for internal use by
the compiler and can be ignored by the programmer. However, sometimes
when a buggy program raises an exception, one of these files comes
popping up into view. It might help your understanding of the problem to
have seen these files before they mysteriously appear in front of your
face. However, don’t try to edit these files to fix the problem! The
real problem is probably somewhere in the corresponding XAML file.
In the root element of MainPage.xaml you’ll see settings for FontFamily, FontSize, and Foreground that apply to the whole page.
The body of the MainPage.xaml file contains several nested elements named Grid, StackPanel, and TextBlock in a parent-child hierarchy.
Notice the word I used: element. In Silverlight
programming, this word has two related meanings. It’s an XML term used
to indicate items delimited by start tags and end tags. But it’s also a
word used in Silverlight to refer to visual objects, and in fact, the word element shows up in the names of two actual Silverlight classes.
Many of the classes you use in Silverlight are part of this important class hierarchy:
Object
DependencyObject (abstract)
UIElement (abstract)
FrameworkElement (abstract)
Besides UIElement, many other Silverlight classes derive from DependencyObject. But UIElement has the distinction of being the class that has the power to appear as a visual object on the screen and to receive user
input. (In Silverlight, all visual objects can receive user input.)
Traditionally, this user input comes from the keyboard and mouse; on the
phone, most user input comes from touch.
The only class that derives from UIElement is FrameworkElement.
The distinction between these two classes is a historical artifact of
the Windows Presentation Foundation. In WPF, it is possible for
developers to create their own unique frameworks by deriving from UIElement. In Silverlight this is not possible, so the distinction is fairly meaningless.
One of the classes that derives from FrameworkElement is Control, a word more common than element in traditional graphical user-interface programming. Some objects commonly referred to as controls in other programming environments are more correctly referred to as elements in Silverlight.
Another class that derives from FrameworkElement is Panel, which is the parent class to the Grid and StackPanel elements you see in MainPage.xaml. Panels
are elements that can host multiple children and arrange them in
particular ways on the screen.
Another class that derives from FrameworkElement is TextBlock, the element you’ll use most often in displaying blocks of text up to about a paragraph in length. The two TextBlock elements in MainPage.xaml display the two chunks of title text in a new Silverlight program.
PhoneApplicationPage, Grid, StackPanel, and TextBlock are all Silverlight classes. In Markup these become XML elements. Properties of these classes become XML attributes.
The nesting of elements in MainPage.xaml is said to define a visual tree. In a Silverlight program for Windows Phone 7, the visual tree always begins with an object of type PhoneApplicationFrame,
which occupies the entire visual surface of the phone. A Silverlight
program for Windows Phone 7 always has one and only one instance of PhoneApplicationFrame, referred to informally as the frame.
In contrast, a program can have multiple instances of PhoneApplicationPage, referred to informally as a page. At any one time, the frame hosts one page, but lets you navigate to the other pages. By default, the page does not occupy the full display surface of the frame because it makes room for the system tray (also known as the status bar) at the top of the phone.
Our simple application has only one page, appropriately called MainPage. This MainPage contains a Grid, which contains a StackPanel with a couple TextBlockGrid, all in a hierarchical tree. The visual tree of a Silverlight program creates by Visual Studio is: elements, and another
PhoneApplicationFrame
PhoneApplicationPage
Grid named "LayoutRoot"
StackPanel named "TitlePanel"
TextBlock named "ApplicationTitle"
TextBlock named "PageTitle"
Grid named "ContentPanel"
Our original goal was to
create a Silverlight program that displays some text in the center of
the display, but given the presence of a couple titles, let’s amend that
goal to displaying the text in the center of the page apart from the
titles. The area of the page for program content is the Grid towards the bottom of the file preceded by the comment “ContentPanel - place additional content here.” This Grid has a name of “ContentPanel” and I’m going to refer to it informally as the “content panel” or “content grid”. The area of the screen corresponding to this Grid apart from the titles I’ll often refer to as the “content area”.
In the content grid, you can insert a new TextBlock:
Example 5. Silverlight Project: SilverlightHelloPhone File: MainPage.xaml (excerpt)
<Grid x:Name="ContentPanel" Grid.Row="1" Margin="12,0,12,0">
<TextBlock Text="Hello, Windows Phone 7!"
HorizontalAlignment="Center"
VerticalAlignment="Center" />
</Grid>
|
Text, HorizontalAlignment, and VerticalAlignment are all properties of the TextBlock class. The Text property is of type string. The HorizontalAlignment and VerticalAlignment properties are of numeration types HorizontalAlignment and VerticalAlignment, respectively. When you reference an enumeration type in XAML, you only need the member name.
While you’re editing MainPage.xaml you might also want to fix the other TextBlock elements so that they aren’t so generic. Change
<TextBlock . . . Text="MY APPLICATION" . . . />
to
<TextBlock . . . Text="SILVERLIGHT HELLO PHONE" . . . />
and
<TextBlock . . . Text="page title" . . . />
to:
<TextBlock . . . Text="main page" . . . />
It doesn’t make much sense to
have a page title in a Silverlight application with only a single page,
and you can delete that second TextBlock
if you’d like. The changes you make to this XAML file will be reflected
in the design view. You can now compile and run this program:
This screen shot—and most
of the remaining screen shots in this book—are shown on the pages of
this book with a size that approximates the size of the actual phone,
surrounded by some simple “chrome” that symbolizes either the actual
phone or the phone emulator.
As simple as it is, this program demonstrates some essential concepts of Silverlight programming, including dynamic
layout. The XAML file defines a layout of elements in a visual tree.
These elements are capable of arranging themselves dynamically. The HorizontalAlignment and VerticalAlignment
properties can put an element in the center of another element, or (as
you might suppose) along one of the edges or in one of the corners. TextBlock
is one of a number of possible elements you can use in a Silverlight
program; others include bitmap images, movies, and familiar controls
like buttons, sliders, and list boxes.
